Skip to main content

ANALYSIS: Hostname Inventory

Kibana Dashboard: [INVENTORY] Hosts

What is this baseline?​

The associated Kibana dashboard represents the baseline inventory of hostnames observed within the DAL.

  • A host entry consists of:
    • host.hostname
    • One or more associated host.ip values
    • One or more associated host.os.name values (when available)
  • Each row answers:

    "Was this hostname observed in the baseline inventory?"

  • This is not an asset management system:
    • No guarantee the host is still online
    • No lifecycle or state tracking
    • No assurance the hostname is authoritative
  • A single corroborated observation is enough to add a hostname to the baseline.
How the baseline is built
  • Entries are deduplicated by hostname
  • Hostnames are normalized (short name, lowercased)
  • A hostname is added if it can be correlated to a DAL IP
  • @timestamp reflect when the hostname was last observed

Data Prerequisites​

note

If any of these are missing or incorrect, the baseline is unreliable.

1. DAL / HOME_NET must be correct​

  • Derived from Zeek and/or Suricata HOME_NET
  • Used to determine which IPs are considered internal
  • Hostnames are only inventoried when they correlate to DAL IPs
  • Incorrect DAL → missing hosts or misattributed assets

2. Required telemetry sources (at least one)​

  • Zeek (conn, dns, dhcp, ntlm)
  • Winlogbeat / Sysmon
  • Auditbeat
  • Endgame
  • Metasponse (any collector)

NOTE: Hostnames are heavily dependent on correlation.
Sparse telemetry will result in partial or delayed hostname discovery.

Basic Analysis Workflow​

1. Baseline sanity check​

Start by validating expected inventory size and composition:

  • Known hosts are present
  • Hostnames align with mission topology
  • OS distributions make sense (e.g., servers vs workstations)
  • No obvious junk hostnames (e.g., random strings, malformed names)

Unexpected absences usually indicate missing telemetry, not stealth.

2. Long-tail analysis (primary value)​

Focus on unaccounted hosts or unexpected hostnames

  • Hostnames that don't follow standardized schemas
  • Hosts with uncommon OS values

Key questions

  • A transient system (jump host, installer, scanner)?
  • A renamed system?
  • An unauthorized or rogue device?

Validate against

  • Mission documentation
  • Asset lists
  • Network diagrams
  • Admin confirmation if required

3. IP and OS correlation review​

Multiple IPs per hostname

  • Normal for DHCP environments
  • Suspicious if crossing security zones or VLANs

Multiple OS values per hostname

  • Often indicates telemetry drift or reimaging
  • Rarely benign if simultaneous

Both cases warrant clarification, not immediate escalation.

4. Export for reporting and diffing​

note

Reporting and documentation requirements are determined by the Mission Element Lead/Crew Lead

Common exports

  • Full Inventory table (CSV)
  • Hostname + IP + OS mapping

NOTE: These exports represent the declared host baseline for the mission period.

5. Enable baseline deviation detection rule​

caution

Enabling too early guarantees noise - it will alert on ALL new inventory additions after enablement.

tip

Detection rules can be managed in Kibana under Security → Rules

Rule: [262][Inventory] New hostname added to baseline​

  • Detection logic:

    Alert when a new hostname within the DAL is added to the baseline inventory

  • Only enable after:
    • Baseline window is complete
    • All expected hosts are observed
    • Long-tail hostname review is finished
  • Ongoing alert tuning:
    • Whitelist known late-arriving assets
    • Suppress ephemeral or mission-support systems
    • Validate hostname legitimacy before escalation

This rule is intended to catch:

  • Rogue hosts
  • Unauthorized additions